1. Technical Field
Embodiments generally relate to device aggregation for a computer platform. More particularly, certain embodiments relate to representing a resource in one physical device of a computer platform to a host OS as residing in another physical device of the computer platform.
2. Background Art
In a conventional computer platform, a storage host bus adapter (HBA) provides for a host an interface to one or more platform devices (e.g. disks) and/or a network HBA provides for the host an interface to one or more network devices. A host operating system (OS) of such a computer platform traditionally treats each adapter device attached directly to a host bus as an independent entity, where each of the attached devices is managed by an independent device driver instance.
For example, FIG. 1 illustrates a conventional computer platform 100 including hardware 110 and software 105 which executes, for example, with a processor and memory (not shown) of computer platform 100. Hardware 110 includes both a storage HBA 170a and a network HBA 170b and a host bus 160—for example, a Peripheral Component Interconnect (PCI) bus, PCI Express bus, and/or the like—coupled thereto. Storage HBA 170a makes an adapted device—e.g. a disk 180—available for the host to access via host bus 160, where storage HBA 170a terminates transactions on the host-facing side, and instantiates a substitute set of transactions (of a protocol different from that of the host-bus) on the device-facing side. Storage HBA 170a is able to do so as it deals with a host bus 160 addressing domain that is different from the device bus 190 addressing domain.
Under current techniques, a driver A 140a and a separate driver B 140b of software 105 are needed to operate storage HBA 170a and network HBA 170b, respectively. A host OS 125 of software 105 includes an OS input/output (I/O) stack 120 for storing I/O information, and an OS I/O interface 130 for host OS 125 to perform respective I/O with storage HBA 170a and network HBA 170b by variously exchanging I/O information with various driver processes such as driver A 140a and driver B 140b. 
An increasing number and variety of I/O devices, such as PCIe-based storage devices (e.g. PCIe SSDs, PCIe Hybrid drives) for example, are capable of attaching to a host bus directly—e.g. by virtue of their capacity for fast bus communication rates—without the need of any intermediary HBA. Directly coupling such devices to a host bus moves the burden of aggregation of such devices to host software. Conventionally, host OS 125 is needed to manage aggregation across multiple directly-coupled host bus devices through their respective drivers (for example driver A 140a and driver B 140b).
However, aggregation at layers above driver A 140a and driver B 140b poses many problems, including long latency, for example. In the architecture of some host OSes, for example, driver instances (even for similar I/O devices) are not permitted to communicate directly with each other, except through upper layer filter drivers (not shown). Moreover, some OSs require OS I/O interface 130 to include functionality to handle PCI-level hardware events (e.g. hotplug, power, errors, and designating driver load order). Linux OSs do not even support hot-plugging of some host bus switches, for example. Various events specific to the host bus, such as PCI-related or PCIe-related events, are currently handled directly by the OS's host bus driver processes—e.g. PCIe bus driver instances 150a, 150b—leaving no opportunity for the individual I/O device driver instances to coordinate an aggregation-aware response. For example, various I/O device insertions, removals, errors, or power state events are handled at host OS 125. Each child device driver instance is not expected to behave as its parent volume driver, since, for example, only its parent volume driver holds knowledge and expected behavior of the multiple child devices as a volume. Such problems make it difficult for separate I/O device driver instances to efficiently provide coordinated device aggregation.